Solución de problemas de la pila de redes definidas por software de Windows Server

  • Artículo

En esta guía se examinan los escenarios comunes de errores y errores de redes definidas por software (SDN) y se describe un flujo de trabajo de solución de problemas que usa las herramientas de diagnóstico disponibles. Para obtener más información sobre SDN, consulte Redes definidas por software.

Se aplica a: Windows Server 2022, Windows Server 2019, Windows Server 2016, Azure Stack HCI, versiones 21H2 y 20H2

Tipos de error

La lista siguiente representa la clase de problemas que se suelen ver con la virtualización de red de Hyper-V (HNVv1) en Windows Server 2012 R2 a partir de implementaciones de producción en el mercado y coincide de muchas maneras con los mismos tipos de problemas detectados en Windows Server 2016 HNVv2 con la nueva pila de red definida por software (SDN).

La mayoría de los errores se pueden clasificar en un pequeño conjunto de clases:

  • Configuración no válida o no admitida

    Un usuario invoca la API NorthBound incorrectamente o con una directiva no válida.

  • Error en la aplicación de directiva

    La directiva de controladora de red no se entregó a un host de Hyper-V, se retrasó o no se actualizó en todos los hosts de Hyper-V (por ejemplo, después de una migración en vivo).

  • Desfase de configuración o error de software

    Problemas de ruta de acceso de datos que dan lugar a paquetes eliminados.

  • Error externo relacionado con el hardware o los controladores de NIC o el tejido de red subyacente

    Descarga de tareas de comportamiento erróneo (como VMQ) o tejido de red subyacente mal configurado (por ejemplo, MTU)

    En esta guía de solución de problemas se examina cada una de estas categorías de error y se recomiendan los procedimientos recomendados y las herramientas de diagnóstico disponibles para identificar y corregir el error.

Herramientas de diagnóstico

Antes de analizar los flujos de trabajo de solución de problemas de cada uno de estos tipos de errores, vamos a examinar las herramientas de diagnóstico disponibles.

Para usar las herramientas de diagnóstico controladora de red (ruta de acceso de control), primero debe instalar la RSAT-NetworkController característica e importar el NetworkControllerDiagnostics módulo:

Add-WindowsFeature RSAT-NetworkController -IncludeManagementTools
Import-Module NetworkControllerDiagnostics

Para usar las herramientas de diagnóstico de HNV Diagnostics (data-path), debe importar el HNVDiagnostics módulo:

# Assumes RSAT-NetworkController feature has already been installed
Import-Module hnvdiagnostics

Diagnóstico de controlador de red

Estos cmdlets se documentan en TechNet en el cmdlet Network Controller Diagnostics. Ayudan a identificar problemas con la coherencia de la directiva de red en la ruta de acceso de control entre los nodos de controlador de red y entre la controladora de red y los agentes de host NC que se ejecutan en los hosts de Hyper-V.

Los Debug-ServiceFabricNodeStatus cmdlets y Get-NetworkControllerReplica deben ejecutarse desde una de las máquinas virtuales de nodo de controladora de red. Todos los demás cmdlets de diagnóstico de NC se pueden ejecutar desde cualquier host, que tenga conectividad con la controladora de red y se encuentra en el grupo de seguridad administración de controladores de red (Kerberos) o tenga acceso al certificado X.509 para administrar el controlador de red.

Diagnóstico de host de Hyper-V

Estos cmdlets se documentan en TechNet en el cmdlet diagnóstico de virtualización de red de Hyper-V (HNV). Ayudan a identificar problemas en la ruta de acceso de datos entre las máquinas virtuales de inquilino (Este/Oeste) y el tráfico de entrada a través de una VIP de SLB (Norte/Sur).

, Debug-VirtualMachineQueueOperation, , , , , Get-VMSwitchExternalPortIdy Test-EncapOverheadSettings son todas las pruebas locales que se pueden ejecutar desde cualquier host de Hyper-V. Get-VMNetworkAdapterPortIdGet-ProviderAddressGet-PACAMappingGet-CustomerRoute Los demás cmdlets invocan pruebas de ruta de acceso a datos a través de la controladora de red y, por tanto, necesitan acceso a la controladora de red, como se describió anteriormente.

GitHub

El repositorio de GitHub de Microsoft/SDN tiene muchos scripts y flujos de trabajo de ejemplo que se basan en estos cmdlets integrados. En concreto, los scripts de diagnóstico se pueden encontrar en la carpeta Diagnósticos . Ayúdenos a contribuir a estos scripts mediante el envío de solicitudes de incorporación de cambios.

Solución de problemas de flujos de trabajo y guías

[Hoster] Validación del estado del sistema

Hay un recurso incrustado denominado Estado de configuración en varios de los recursos de controlador de red. El estado de configuración proporciona información sobre el estado del sistema, incluida la coherencia entre la configuración del controlador de red y el estado real (en ejecución) en los hosts de Hyper-V.

Para comprobar el estado de configuración, ejecute lo siguiente desde cualquier host de Hyper-V con conectividad con la controladora de red.

Nota:

El valor del NetworkController parámetro debe ser el FQDN o la dirección IP en función del nombre del firmante del certificado X.509 >creado para la controladora de red.

El Credential parámetro solo debe especificarse si la controladora de red usa la autenticación Kerberos (habitual en las implementaciones de VMM). La credencial debe ser para un usuario que esté en el grupo de seguridad de administración de controladores de red.

Debug-NetworkControllerConfigurationState -NetworkController <FQDN or NC IP> [-Credential <PS Credential>]

# Healthy State Example - no status reported
$cred = Get-Credential
Debug-NetworkControllerConfigurationState -NetworkController 10.127.132.211 -Credential $cred

Fetching ResourceType:     accessControlLists
Fetching ResourceType:     servers
Fetching ResourceType:     virtualNetworks
Fetching ResourceType:     networkInterfaces
Fetching ResourceType:     virtualGateways
Fetching ResourceType:     loadbalancerMuxes
Fetching ResourceType:     Gateways

A continuación se muestra un mensaje de estado de configuración de ejemplo:

Fetching ResourceType:     servers
---------------------------------------------------------------------------------------------------------
ResourcePath:     https://10.127.132.211/Networking/v1/servers/4c4c4544-0056-4b10-8058-b8c04f395931
Status:           Warning

Source:           SoftwareLoadBalancerManager
Code:             HostNotConnectedToController
Message:          Host is not Connected.
----------------------------------------------------------------------------------------------------------

Nota:

Hay un error en el sistema en el que los recursos de interfaz de red para la NIC de la máquina virtual de tránsito de Mux de SLB están en un estado de error con el error "Conmutador virtual - Host no conectado al controlador". Este error se puede omitir de forma segura si la configuración de IP en el recurso nic de máquina virtual se establece en una dirección IP del grupo de direcciones IP de la red lógica de tránsito.

Hay un segundo error en el sistema en el que los recursos de interfaz de red para las NIC de máquina virtual del proveedor de HNV de puerta de enlace están en un estado de error con el error "Conmutador virtual - PortBlocked". Este error también se puede omitir de forma segura si la configuración de IP en el recurso nic de máquina virtual se establece en null (por diseño).

En la tabla siguiente se muestra la lista de códigos de error, mensajes y acciones de seguimiento que se deben realizar en función del estado de configuración observado.

Código Mensaje Acción
Unknown Error desconocido
HostUnreachable No se puede acceder a la máquina host Comprobación de la conectividad de red de administración entre la controladora de red y el host
PAIpAddressExhausted Direcciones IP de PA agotadas Aumentar el tamaño del grupo de IP de la subred lógica del proveedor de HNV
PAMacAddressExhausted Direcciones MAC de PA agotadas Aumento del intervalo de grupos de Mac
PAAddressConfigurationFailure No se pudieron conectar direcciones PA al host Compruebe la conectividad de red de administración entre la controladora de red y el host.
CertificateNotTrusted El certificado no es de confianza Corrija los certificados usados para la comunicación con el host.
CertificateNotAuthorized Certificado no autorizado Corrija los certificados usados para la comunicación con el host.
PolicyConfigurationFailureOnVfp Error al configurar directivas de VFP Se trata de un error en tiempo de ejecución. No hay soluciones alternativas definitivas. Recopilar los registros
PolicyConfigurationFailure Error al insertar directivas en los hosts, debido a errores de comunicación u otros errores en NetworkController. No hay acciones definidas. Esto se debe a un error en el procesamiento de estado de objetivo en los módulos de controlador de red. Recopilar los registros
HostNotConnectedToController El host aún no está conectado a la controladora de red El perfil de puerto no se aplica en el host o el host no es accesible desde la controladora de red. Validar que la clave del Registro HostID coincide con el identificador de instancia del recurso de servidor
MultipleVfpEnabledSwitches Hay varios conmutadores habilitados para VFp en el host Elimine uno de los modificadores, ya que el Agente host de controlador de red solo admite un vSwitch con la extensión VFP habilitada.
PolicyConfigurationFailure Error al insertar directivas de red virtual para un vmNic debido a errores de certificado o errores de conectividad Compruebe si se han implementado los certificados adecuados (el nombre del firmante del certificado debe coincidir con el FQDN del host). Compruebe también la conectividad del host con la controladora de red.
PolicyConfigurationFailure Error al insertar directivas de vSwitch para un vmNic debido a errores de certificado o errores de conectividad Compruebe si se han implementado los certificados adecuados (el nombre del firmante del certificado debe coincidir con el FQDN del host). Compruebe también la conectividad del host con la controladora de red.
PolicyConfigurationFailure Error al insertar directivas de firewall para vmNic debido a errores de certificado o errores de conectividad Compruebe si se han implementado los certificados adecuados (el nombre del firmante del certificado debe coincidir con el FQDN del host). Compruebe también la conectividad del host con la controladora de red.
DistributedRouterConfigurationFailure No se pudo configurar la configuración del enrutador distribuido en el host vNic Error de pila TCPIP. Puede que sea necesario limpiar las vNIC del host de recuperación ante desastres y pa en el servidor en el que se ha notificado este error.
DhcpAddressAllocationFailure Error en la asignación de direcciones DHCP para un VMNic Compruebe si el atributo de dirección IP estática está configurado en el recurso nic.
CertificateNotTrusted
CertificateNotAuthorized		 Error al conectarse a Mux debido a errores de red o certificado Compruebe el código numérico proporcionado en el código del mensaje de error: corresponde al código de error winsock. Los errores de certificado son granulares (por ejemplo, no se puede comprobar el certificado, el certificado no autorizado, etc.).
HostUnreachable MUX es incorrecto (el caso común es BGPRouter desconectado) El par BGP en el conmutador RRAS (máquina virtual BGP) o de parte superior del bastidor (ToR) no es accesible o no se empareja correctamente. Compruebe la configuración de BGP en el recurso De software Load Balancer Multiplexer y en el par BGP (máquina virtual ToR o RRAS)
HostNotConnectedToController El agente de host de SLB no está conectado Compruebe que se está ejecutando el servicio del Agente de host de SLB; Consulte los registros del agente de host de SLB (ejecución automática) por motivos por los que, en caso de que SLBM (NC) rechazara el certificado presentado por el estado de ejecución del agente host, se mostrará información matizada.
PortBlocked El puerto VFP está bloqueado, debido a la falta de directivas de VNET/ACL Compruebe si hay algún otro error, lo que podría hacer que las directivas no se configuren.
Sobrecargado La experiencia de usuario del equilibrador de carga está sobrecargada Problema de rendimiento con MUX
RoutePublicationFailure La experiencia de usuario del equilibrador de carga no está conectada a un enrutador BGP Compruebe si MUX tiene conectividad con los enrutadores BGP y que el emparejamiento BGP está configurado correctamente.
VirtualServerUnreachable La experiencia de usuario del equilibrador de carga no está conectada al administrador de SLB Comprobación de la conectividad entre SLBM y MUX
QosConfigurationFailure Error al configurar directivas de QOS Vea si hay suficiente ancho de banda disponible para todas las máquinas virtuales si se usa la reserva de QOS.

Comprobación de la conectividad de red entre la controladora de red y el host de Hyper-V (servicio agente de host NC)

Ejecute el netstat siguiente comando para validar que hay tres ESTABLISHED conexiones entre el agente de host NC y los nodos de controlador de red y un LISTENING socket en el host de Hyper-V.

  • LISTENING on port TCP:6640 on Hyper-V Host (NC Host Agent Service)
  • Dos conexiones establecidas desde la dirección IP del host de Hyper-V en el puerto 6640 a la dirección IP del nodo NC en puertos efímeros (> 32000)
  • Una conexión establecida desde la dirección IP del host de Hyper-V en el puerto efímero a la dirección IP REST de la controladora de red en el puerto 6640

Nota:

Solo puede haber dos conexiones establecidas en un host de Hyper-V si no hay máquinas virtuales de inquilino implementadas en ese host determinado.

netstat -anp tcp |findstr 6640

# Successful output
  TCP    0.0.0.0:6640           0.0.0.0:0              LISTENING
  TCP    10.127.132.153:6640    10.127.132.213:50095   ESTABLISHED
  TCP    10.127.132.153:6640    10.127.132.214:62514   ESTABLISHED
  TCP    10.127.132.153:50023   10.127.132.211:6640    ESTABLISHED

Comprobación de los servicios del agente host

La controladora de red se comunica con dos servicios de agente de host en los hosts de Hyper-V: agente de host de SLB y agente de host NC. Es posible que uno o ambos servicios no se estén ejecutando. Compruebe su estado y reinicie si no se están ejecutando.

Get-Service SlbHostAgent
Get-Service NcHostAgent

# (Re)start requires -Force flag
Start-Service NcHostAgent -Force
Start-Service SlbHostAgent -Force

Comprobación del estado de la controladora de red

Si no hay tres ESTABLISHED conexiones o si la controladora de red no responde, compruebe que todos los nodos y módulos de servicio están en funcionamiento mediante los siguientes cmdlets.

# Prints a DIFF state (status is automatically updated if state is changed) of a particular service module replica
Debug-ServiceFabricNodeStatus [-ServiceTypeName] <Service Module>

Los módulos de servicio de controlador de red son:

  • ControllerService
  • ApiService
  • SlbManagerService
  • ServiceInsertion
  • FirewallService
  • VSwitchService
  • GatewayManager
  • FnmService
  • HelperService
  • UpdateService

Compruebe que ReplicaStatus es Ready y HealthState es Ok.

En una implementación de producción con una controladora de red de varios nodos, también puede comprobar en qué nodo es principal cada servicio y su estado de réplica individual.

Get-NetworkControllerReplica

# Sample Output for the API service module
Replicas for service: ApiService

ReplicaRole   : Primary
NodeName      : SA18N30NC3.sa18.nttest.microsoft.com
ReplicaStatus : Ready

Compruebe que el estado de réplica está listo para cada servicio.

Compruebe si hay certificados y identificadores de host correspondientes entre la controladora de red y cada host de Hyper-V.

En un host de Hyper-V, ejecute los siguientes cmdlets para comprobar que hostID corresponde al identificador de instancia de un recurso de servidor en la controladora de red.

Get-ItemProperty "hklm:\system\currentcontrolset\services\nchostagent\parameters" -Name HostId |fl HostId

HostId : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**

Get-NetworkControllerServer -ConnectionUri $uri |where { $_.InstanceId -eq "162cd2c8-08d4-4298-8cb4-10c2977e3cfe"}

Tags             :
ResourceRef      : /servers/4c4c4544-0056-4a10-8059-b8c04f395931
InstanceId       : **162cd2c8-08d4-4298-8cb4-10c2977e3cfe**
Etag             : W/"50f89b08-215c-495d-8505-0776baab9cb3"
ResourceMetadata : Microsoft.Windows.NetworkController.ResourceMetadata
ResourceId       : 4c4c4544-0056-4a10-8059-b8c04f395931
Properties       : Microsoft.Windows.NetworkController.ServerProperties

Remediación

Si usa scripts de SDNExpress o implementación manual, actualice la clave HostId en el Registro para que coincida con el identificador de instancia del recurso de servidor. Reinicie el Agente de host de controladora de red en el host de Hyper-V (servidor físico) Si usa VMM, elimine el servidor de Hyper-V de VMM y quite la clave del Registro HostId. A continuación, vuelva a agregar el servidor a través de VMM.

Compruebe que las huellas digitales de los certificados X.509 usados por el host de Hyper-V (el nombre de host será el nombre de firmante del certificado) para la comunicación entre el host de Hyper-V (servicio agente de host NC) y los nodos de controlador de red son los mismos. Compruebe también que el certificado REST de la controladora de red tiene el nombre de firmante de CN=<FQDN or IP>.

# On Hyper-V Host
dir cert:\\localmachine\my

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
...

dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**

# On Network Controller Node VM
dir cert:\\localmachine\root

Thumbprint                                Subject
----------                                -------
2A3A674D07D8D7AE11EBDAC25B86441D68D774F9  CN=SA18n30-4.sa18.nttest.microsoft.com
30674C020268AA4E40FD6817BA6966531FB9ADA4  CN=10.127.132.211 **# NC REST IP ADDRESS**
...

También puede comprobar los siguientes parámetros de cada certificado para asegurarse de que el nombre del firmante es lo que se espera (nombre de host o FQDN rest nc o IP), que el certificado aún no ha expirado y que todas las entidades de certificación de la cadena de certificados se incluyen en la entidad de certificación raíz de confianza.

  • Subject Name
  • Fecha de caducidad
  • Confianza de la entidad de certificación raíz

Si varios certificados tienen el mismo nombre de firmante en el host de Hyper-V, el Agente de host de controlador de red elegirá aleatoriamente uno para presentarlo a la controladora de red. Es posible que esto no coincida con la huella digital del recurso de servidor conocido por la controladora de red. En este caso, elimine uno de los certificados con el mismo nombre de firmante en el host de Hyper-V y reinicie el servicio Agente de host de controlador de red. Si todavía no se puede realizar una conexión, elimine el otro certificado con el mismo nombre de firmante en el host de Hyper-V y elimine el recurso de servidor correspondiente en VMM. A continuación, vuelva a crear el recurso de servidor en VMM, que generará un nuevo certificado X.509 e instalarlo en el host de Hyper-V.

Comprobación del estado de configuración de SLB

El estado de configuración de SLB se puede determinar como parte de la salida del Debug-NetworkController cmdlet. Este cmdlet también generará el conjunto actual de recursos de controlador de red en archivos JSON, todas las configuraciones IP de cada host de Hyper-V (servidor) y la directiva de red local de las tablas de base de datos del Agente de host.

De forma predeterminada, se recopilarán más seguimientos. Para no recopilar seguimientos, agregue el -IncludeTraces:$false parámetro .

Debug-NetworkController -NetworkController <FQDN or IP> [-Credential <PS Credential>] [-IncludeTraces:$false]

# Don't collect traces
$cred = Get-Credential
Debug-NetworkController -NetworkController 10.127.132.211 -Credential $cred -IncludeTraces:$false

Transcript started, output file is C:\NCDiagnostics.log
Collecting Diagnostics data from NC Nodes

Nota:

La ubicación de salida predeterminada será el <directorio working_directory>\NCDiagnostics\. El directorio de salida predeterminado se puede cambiar mediante el -OutputDirectory parámetro .

La información de estado de configuración de SLB se puede encontrar en el archivo diagnostics-slbstateResults.Json de este directorio.

Este archivo JSON se puede dividir en las secciones siguientes:

  • Tela
    • SlbmVips: en esta sección se muestra la dirección IP de la dirección VIP del administrador de SLB, que usa el controlador de red para coordinar la configuración y el estado entre los Muxes de SLB y los agentes de host de SLB.
    • MuxState: en esta sección se mostrará un valor para cada Mux de SLB implementado que proporciona el estado del mux.
    • Configuración del enrutador: esta sección enumerará el número de sistema autónomo (ASN) del enrutador ascendente (BGP peer), la dirección IP de tránsito y el identificador. También enumerará los Muxes ASN de SLB y la dirección IP de tránsito.
    • Información del host conectado: en esta sección se mostrará la dirección IP de administración de todos los hosts de Hyper-V disponibles para ejecutar cargas de trabajo con equilibrio de carga.
    • Intervalos vip: en esta sección se enumeran los intervalos de grupos de DIRECCIONES VIP públicas y privadas. La VIP SLBM se incluirá como una dirección IP asignada de uno de estos intervalos.
    • Rutas de Mux: en esta sección se muestra un valor para cada Mux de SLB implementado que contiene todos los anuncios de ruta para ese mux determinado.
  • Tenant
    • VipConsolidatedState: en esta sección se mostrará el estado de conectividad de cada VIP de inquilino, incluidos el prefijo de ruta anunciado, el host de Hyper-V y los puntos de conexión DIP.

Nota:

El estado de SLB se puede determinar directamente mediante el script DumpSlbRestState disponible en el repositorio de GitHub de Microsoft SDN.

Validación de puerta de enlace

Desde la controladora de red:

Get-NetworkControllerLogicalNetwork
Get-NetworkControllerPublicIPAddress
Get-NetworkControllerGatewayPool
Get-NetworkControllerGateway
Get-NetworkControllerVirtualGateway
Get-NetworkControllerNetworkInterface

Desde la máquina virtual de puerta de enlace:

Ipconfig /allcompartments /all
Get-NetRoute -IncludeAllCompartments -AddressFamily
Get-NetBgpRouter
Get-NetBgpRouter | Get-BgpPeer
Get-NetBgpRouter | Get-BgpRouteInformation

Desde la parte superior del conmutador del bastidor (ToR):

sh ip bgp summary (for 3rd party BGP Routers)

Enrutador BGP de Windows:

Get-BgpRouter
Get-BgpPeer
Get-BgpRouteInformation

Además de estos, a partir de los problemas que hemos visto hasta ahora (especialmente en las implementaciones basadas en SDNExpress), la razón más común para que Tenant Compartment no se configure en máquinas virtuales GW parece ser el hecho de que la capacidad de GW en FabricConfig.psd1 es menor en comparación con lo que la gente intenta asignar a la red Connections (túneles S2S) en TenantConfig.psd1. Esto se puede comprobar fácilmente comparando las salidas de los siguientes cmdlets:

PS > (Get-NetworkControllerGatewayPool -ConnectionUri $uri).properties.Capacity
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").properties.OutboundKiloBitsPerSecond
PS > (Get-NetworkControllerVirtualgatewayNetworkConnection -ConnectionUri $uri -VirtualGatewayId "TenantName").property

[Hoster] Validar Data-Plane

Una vez implementada la controladora de red, se han creado redes virtuales de inquilino y subredes, y las máquinas virtuales se han conectado a las subredes virtuales, el host puede realizar pruebas adicionales de nivel de tejido para comprobar la conectividad del inquilino.

Comprobación de la conectividad de red lógica del proveedor HNV

Una vez que la primera máquina virtual invitada que se ejecuta en un host de Hyper-V se ha conectado a una red virtual de inquilino, la controladora de red asignará dos direcciones IP del proveedor de HNV (direcciones IP de PA) al host de Hyper-V. Estas direcciones IP procederán del grupo de direcciones IP de la red lógica del proveedor de HNV y la administrará el controlador de red. Para averiguar cuáles son estas dos direcciones IP de HNV:

PS > Get-ProviderAddress

# Sample Output
ProviderAddress : 10.10.182.66
MAC Address     : 40-1D-D8-B7-1C-04
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

ProviderAddress : 10.10.182.67
MAC Address     : 40-1D-D8-B7-1C-05
Subnet Mask     : 255.255.255.128
Default Gateway : 10.10.182.1
VLAN            : VLAN11

Estas direcciones IP del proveedor de HNV (IP pa) se asignan a los adaptadores Ethernet creados en un compartimiento de red TCPIP independiente y tienen un nombre de adaptador de VLANX donde X es la VLAN asignada a la red lógica del proveedor de HNV (transporte).

La conectividad entre dos hosts de Hyper-V mediante la red lógica del proveedor de HNV se puede realizar mediante un ping con un parámetro de compartimiento adicional (-c Y) donde Y es el compartimiento de red TCPIP en el que se crean los PAhostVNICs. Este compartimiento se puede determinar mediante la ejecución de:

C:\> ipconfig /allcompartments /all

<snip> ...
==============================================================================
Network Information for *Compartment 3*
==============================================================================
   Host Name . . . . . . . . . . . . : SA18n30-2
<snip> ...

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-04
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::5937:a365:d135:2899%39(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.66(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

Ethernet adapter VLAN11:

   Connection-specific DNS Suffix  . :
   Description . . . . . . . . . . . : Microsoft Hyper-V Network Adapter
   Physical Address. . . . . . . . . : 40-1D-D8-B7-1C-05
   DHCP Enabled. . . . . . . . . . . : No
   Autoconfiguration Enabled . . . . : Yes
   Link-local IPv6 Address . . . . . : fe80::28b3:1ab1:d9d9:19ec%44(Preferred)
   IPv4 Address. . . . . . . . . . . : 10.10.182.67(Preferred)
   Subnet Mask . . . . . . . . . . . : 255.255.255.128
   Default Gateway . . . . . . . . . : 10.10.182.1
   NetBIOS over Tcpip. . . . . . . . : Disabled

*Ethernet adapter vEthernet (PAhostVNic):*
<snip> ...

Nota:

Los adaptadores vNIC de host pa no se usan en la ruta de acceso de datos y, por lo tanto, no tienen una dirección IP asignada al adaptador de vEthernet (PAhostVNic).

Por ejemplo, suponga que los hosts 1 y 2 de Hyper-V tienen direcciones IP del proveedor de HNV (PA) de:

Hyper-V Host Dirección IP 1 de PA Dirección IP pa 2
Host 1 10.10.182.64 10.10.182.65
Host 2 10.10.182.66 10.10.182.67

podemos hacer ping entre los dos mediante el siguiente comando para comprobar la conectividad de red lógica del proveedor de HNV.

# Ping the first PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.64

# Ping the second PA IP Address on Hyper-V Host 2 from the first PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.64

# Ping the first PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.66 -S 10.10.182.65

# Ping the second PA IP Address on Hyper-V Host 2 from the second PA IP address on Hyper-V Host 1 in compartment (-c) 3
C:\> ping -c 3 10.10.182.67 -S 10.10.182.65

Remediación

Si el ping del proveedor de HNV no funciona, compruebe la conectividad de red física, incluida la configuración de VLAN. Las NIC físicas de cada host de Hyper-V deben estar en modo troncal sin ninguna VLAN específica asignada. El vNIC del host de administración debe estar aislado a la VLAN de la red lógica de administración.

PS C:\> Get-NetAdapter "Ethernet 4" |fl

Name                       : Ethernet 4
InterfaceDescription       : <NIC> Ethernet Adapter
InterfaceIndex             : 2
MacAddress                 : F4-52-14-55-BC-21
MediaType                  : 802.3
PhysicalMediaType          : 802.3
InterfaceOperationalStatus : Up
AdminStatus                : Up
LinkSpeed(Gbps)            : 10
MediaConnectionState       : Connected
ConnectorPresent           : True
*VlanID                     : 0*
DriverInformation          : Driver Date 2016-08-28 Version 5.25.12665.0 NDIS 6.60

# VMM uses the older PowerShell cmdlet <Verb>-VMNetworkAdapterVlan to set VLAN isolation
PS C:\> Get-VMNetworkAdapterVlan -ManagementOS -VMNetworkAdapterName <Mgmt>

VMName VMNetworkAdapterName Mode     VlanList
------ -------------------- ----     --------
<snip> ...
       Mgmt                 Access   7
<snip> ...

# SDNExpress deployments use the newer PowerShell cmdlet <Verb>-VMNetworkAdapterIsolation to set VLAN isolation
PS C:\> Get-VMNetworkAdapterIsolation -ManagementOS

<snip> ...

IsolationMode        : Vlan
AllowUntaggedTraffic : False
DefaultIsolationID   : 7
MultiTenantStack     : Off
ParentAdapter        : VMInternalNetworkAdapter, Name = 'Mgmt'
IsTemplate           : True
CimSession           : CimSession: .
ComputerName         : SA18N30-2
IsDeleted            : False

<snip> ...

Comprobación de la compatibilidad con MTU y tramas jumbo en la red lógica del proveedor HNV

Otro problema común en la red lógica del proveedor HNV es que los puertos de red físicos o la tarjeta Ethernet no tienen un MTU lo suficientemente grande configurado para controlar la sobrecarga de la encapsulación VXLAN (o NVGRE).

Nota:

Algunas tarjetas Ethernet y controladores admiten la nueva *EncapOverhead palabra clave que el Agente de host de controlador de red establecerá automáticamente en un valor de 160. A continuación, este valor se agregará al valor de la palabra clave *JumboPacket cuya suma se usa como la MTU anunciada.

Por ejemplo, *EncapOverhead = 160 y *JumboPacket = 1514 => MTU = 1674B

# Check whether or not your Ethernet card and driver support *EncapOverhead
PS C:\ > Test-EncapOverheadSettings

Verifying Physical Nic : <NIC> Ethernet Adapter #2
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Verifying Physical Nic : <NIC> Ethernet Adapter
Physical Nic  <NIC> Ethernet Adapter can support SDN traffic. Encapoverhead value set on the nic is  160

Para probar si la red lógica del proveedor de HNV admite o no el tamaño de MTU de un extremo a otro, use el Test-LogicalNetworkSupportsJumboPacket cmdlet :

# Get credentials for both source host and destination host (or use the same credential if in the same domain)
$sourcehostcred = Get-Credential
$desthostcred = Get-Credential

# Use the Management IP Address or FQDN of the Source and Destination Hyper-V hosts
Test-LogicalNetworkSupportsJumboPacket -SourceHost sa18n30-2 -DestinationHost sa18n30-3 -SourceHostCreds $sourcehostcred -DestinationHostCreds $desthostcred

# Failure Results
SourceCompartment : 3
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1632
pinging Source PA: 10.10.182.66 to Destination PA: 10.10.182.64 with Payload: 1472
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.
Checking if physical nics support jumbo packets on host
Physical Nic  <NIC> Ethernet Adapter #2 can support SDN traffic. Encapoverhead value set on the nic is  160
Cannot send jumbo packets to the destination. Physical switch ports may not be configured to support jumbo packets.

Remediación

  • Ajuste el tamaño de MTU en los puertos del conmutador físico para que sea al menos 1674B (incluido el encabezado Ethernet de 14B y el remolque)
  • Si la tarjeta NIC no admite la palabra clave EncapOverhead, ajuste la palabra clave JumboPacket para que sea al menos 1674B.

Comprobación de la conectividad de NIC de máquina virtual de inquilino

Cada NIC de máquina virtual asignada a una máquina virtual invitada tiene una asignación de CA-PA entre la dirección de cliente (CA) privada y el espacio de dirección del proveedor de HNV (PA). Estas asignaciones se conservan en las tablas de servidor de OVSDB en cada host de Hyper-V y se pueden encontrar mediante la ejecución del siguiente cmdlet.

# Get all known PA-CA Mappings from this particular Hyper-V Host
PS > Get-PACAMapping

CA IP Address CA MAC Address    Virtual Subnet ID PA IP Address
------------- --------------    ----------------- -------------
10.254.254.2  00-1D-D8-B7-1C-43              4115 10.10.182.67
10.254.254.3  00-1D-D8-B7-1C-43              4115 10.10.182.67
192.168.1.5   00-1D-D8-B7-1C-07              4114 10.10.182.65
10.254.254.1  40-1D-D8-B7-1C-06              4115 10.10.182.66
192.168.1.1   40-1D-D8-B7-1C-06              4114 10.10.182.66
192.168.1.4   00-1D-D8-B7-1C-05              4114 10.10.182.66

Nota:

Si las asignaciones de CA-PA que espera no se generan para una máquina virtual de inquilino determinada, compruebe los recursos de configuración de IP y NIC de la máquina virtual en el controlador de red mediante el Get-NetworkControllerNetworkInterface cmdlet . Además, compruebe las conexiones establecidas entre el agente de host NC y los nodos de controlador de red.

Con esta información, el hoster ahora puede iniciar un ping de máquina virtual de inquilino desde la controladora de red mediante el Test-VirtualNetworkConnection cmdlet .

Escenarios de solución de problemas específicos

En las secciones siguientes se proporcionan instrucciones para solucionar problemas de escenarios específicos.

Sin conectividad de red entre dos máquinas virtuales de inquilino

  1. [Inquilino] Asegúrese de que Firewall de Windows en las máquinas virtuales de inquilino no está bloqueando el tráfico.
  2. [Inquilino] Compruebe que las direcciones IP se han asignado a la máquina virtual del inquilino mediante la ejecución de ipconfig.
  3. [Hoster] Ejecute Test-VirtualNetworkConnection desde el host de Hyper-V para validar la conectividad entre las dos máquinas virtuales de inquilino en cuestión.

Nota:

El VSID hace referencia al identificador de subred virtual. En el caso de VXLAN, este es el identificador de red (VNI) VXLAN. Para encontrar este valor, ejecute el Get-PACAMapping cmdlet .

Ejemplo

$password = ConvertTo-SecureString -String "password" -AsPlainText -Force
$cred = New-Object pscredential -ArgumentList (".\administrator", $password)

Cree CA-ping entre "Máquina virtual web verde 1" con la dirección IP de SenderCA de 192.168.1.4 en el host "sa18n30-2.sa18.nttest.microsoft.com" con la dirección IP de Mgmt de 10.127.132.153 a la ip listenerCA de 192.168.1.5, ambos conectados a la subred virtual (VSID) 4114.

Test-VirtualNetworkConnection -OperationId 27 -HostName sa18n30-2.sa18.nttest.microsoft.com -MgmtIp 10.127.132.153 -Creds $cred -VMName "Green Web VM 1" -VMNetworkAdapterName "Green Web VM 1" -SenderCAIP 192.168.1.4 -SenderVSID 4114 -ListenerCAIP 192.168.1.5 -ListenerVSID 4114
Test-VirtualNetworkConnection at command pipeline position 1

Starting CA-space ping test
Starting trace session
Ping to 192.168.1.5 succeeded from address 192.168.1.4
Rtt = 0 ms

CA Routing Information:

    Local IP: 192.168.1.4
    Local VSID: 4114
    Remote IP: 192.168.1.5
    Remote VSID: 4114
    Distributed Router Local IP: 192.168.1.1
    Distributed Router Local MAC: 40-1D-D8-B7-1C-06
    Local CA MAC: 00-1D-D8-B7-1C-05
    Remote CA MAC: 00-1D-D8-B7-1C-07
    Next Hop CA MAC Address: 00-1D-D8-B7-1C-07

PA Routing Information:

    Local PA IP: 10.10.182.66
    Remote PA IP: 10.10.182.65

 <snip> ...

[Inquilino] Compruebe que no hay directivas de firewall distribuidas especificadas en la subred virtual o en las interfaces de red de máquina virtual que bloqueen el tráfico.

Consulte la API REST de controladora de red que se encuentra en el entorno de demostración en sa18n30nc en el dominio sa18.nttest.microsoft.com.

$uri = "https://sa18n30nc.sa18.nttest.microsoft.com"
Get-NetworkControllerAccessControlList -ConnectionUri $uri

Examine la configuración de IP y las subredes virtuales que hacen referencia a esta ACL.

  1. [Hoster] Ejecute Get-ProviderAddress en ambos hosts de Hyper-V que hospedan las dos máquinas virtuales de inquilino en cuestión y, a continuación, ejecute Test-LogicalNetworkConnection o ping -c <compartment> desde el host de Hyper-V para validar la conectividad en la red lógica del proveedor HNV.
  2. [Hoster] Asegúrese de que la configuración de MTU sea correcta en los hosts de Hyper-V y en cualquier dispositivo de conmutación de nivel 2 entre los hosts de Hyper-V. Ejecute Test-EncapOverheadValue en todos los hosts de Hyper-V en cuestión. Compruebe también que todos los switches de capa 2 entre tienen MTU establecido en al menos 1674 bytes para tener en cuenta la sobrecarga máxima de 160 bytes.
  3. [Hoster] Si las direcciones IP de PA no están presentes o la conectividad de CA está interrumpida, compruebe para asegurarse de que se ha recibido la directiva de red. Ejecute Get-PACAMapping para ver si las reglas de encapsulación y las asignaciones de CA-PA necesarias para crear redes virtuales superpuestas se establecen correctamente.
  4. [Hoster] Compruebe que el Agente de host de controlador de red está conectado a la controladora de red. Para ello, ejecute netstat -anp tcp |findstr 6640.
  5. [Hoster] Compruebe que el identificador de host en HKLM/ coincide con el identificador de instancia de los recursos de servidor que hospedan las máquinas virtuales de inquilino.
  6. [Hoster] Compruebe que el identificador de perfil de puerto coincide con el identificador de instancia de las interfaces de red de máquina virtual de las máquinas virtuales de inquilino.

Registro, seguimiento y diagnóstico avanzado

En las secciones siguientes se proporciona información sobre diagnósticos avanzados, registro y seguimiento.

Registro centralizado de controlador de red

La controladora de red puede recopilar automáticamente los registros del depurador y almacenarlos en una ubicación centralizada. La recopilación de registros se puede habilitar al implementar la controladora de red por primera vez o en cualquier momento posterior. Los registros se recopilan de la controladora de red y los elementos de red administrados por la controladora de red: máquinas host, equilibradores de carga de software (SLB) y máquinas de puerta de enlace.

Estos registros incluyen registros de depuración para el clúster de controlador de red, la aplicación controladora de red, los registros de puerta de enlace, el SLB, las redes virtuales y el firewall distribuido. Cada vez que se agrega un nuevo host, SLB o puerta de enlace a la controladora de red, se inicia el registro en esas máquinas. De forma similar, cuando se quita un host, un SLB o una puerta de enlace de la controladora de red, el registro se detiene en esas máquinas.

Habilitación del registro

El registro se habilita automáticamente al instalar el clúster de controlador de red mediante el Install-NetworkControllerCluster cmdlet . De forma predeterminada, los registros se recopilan localmente en los nodos de controlador de red en %systemdrive%\SDNDiagnostics. Se recomienda cambiar esta ubicación para que sea un recurso compartido de archivos remoto (no local).

Los registros del clúster de controladora de red se almacenan en %programData%\Windows Fabric\log\Traces. Puede especificar una ubicación centralizada para la recopilación de registros con el DiagnosticLogLocation parámetro con la recomendación de que también sea un recurso compartido de archivos remoto.

Si desea restringir el acceso a esta ubicación, puede proporcionar las credenciales de acceso con el LogLocationCredential parámetro . Si proporciona las credenciales para acceder a la ubicación del registro, también debe proporcionar el CredentialEncryptionCertificate parámetro , que se usa para cifrar las credenciales almacenadas localmente en los nodos de controladora de red.

Con la configuración predeterminada, se recomienda tener al menos 75 GB de espacio libre en la ubicación central y 25 GB en los nodos locales (si no usa una ubicación central) para un clúster de controlador de red de tres nodos.

Cambiar la configuración de registro

Puede cambiar la configuración de registro en cualquier momento mediante el Set-NetworkControllerDiagnostic cmdlet . Se puede cambiar la siguiente configuración:

  • Ubicación de registro centralizada.

    Puede cambiar la ubicación para almacenar todos los registros, con el DiagnosticLogLocation parámetro .

  • Credenciales para acceder a la ubicación del registro.

    Puede cambiar las credenciales para acceder a la ubicación del registro, con el LogLocationCredential parámetro .

  • Vaya al registro local.

    Si ha proporcionado una ubicación centralizada para almacenar los registros, puede volver al registro localmente en los nodos de controlador de red con el UseLocalLogLocation parámetro (no recomendado debido a los requisitos de espacio en disco grandes).

  • Ámbito de registro.

    De forma predeterminada, se recopilan todos los registros. Puede cambiar el ámbito para recopilar solo los registros de clúster de controladora de red.

  • Nivel de registro.

    El nivel de registro predeterminado es Informativo. Puede cambiarlo a Error, Advertencia o Detallado.

  • Tiempo de antigüedad del registro.

    Los registros se almacenan de forma circular. Tiene tres días de datos de registro de forma predeterminada, ya sea que use el registro local o el registro centralizado. Puede cambiar este límite de tiempo con el LogTimeLimitInDays parámetro .

  • Tamaño de la antigüedad del registro.

    De forma predeterminada, tendrá un máximo de 75 GB de datos de registro si se usa el registro centralizado y 25 GB si se usa el registro local. Puede cambiar este límite con el LogSizeLimitInMBs parámetro .

Recopilación de registros y seguimientos

Las implementaciones de VMM usan el registro centralizado para la controladora de red de forma predeterminada. La ubicación del recurso compartido de archivos para estos registros se especifica al implementar la plantilla de servicio controladora de red.

Si no se ha especificado una ubicación de archivo, se usará el registro local en cada nodo controlador de red con registros guardados en C:\Windows\tracing\SDNDiagnostics. Estos registros se guardan con la siguiente jerarquía:

  • CrashDumps
  • NCApplicationCrashDumps
  • NCApplicationLogs
  • PerfCounters
  • SDNDiagnostics
  • Rastros

La controladora de red usa (Azure) Service Fabric. Es posible que se necesiten registros de Service Fabric al solucionar determinados problemas. Estos registros se pueden encontrar en cada nodo controlador de red en C:\ProgramData\Microsoft\Service Fabric.

Si un usuario ha ejecutado el Debug-NetworkController cmdlet, habrá más registros disponibles en cada host de Hyper-V, que se ha especificado con un recurso de servidor en la controladora de red. Estos registros (y seguimientos si están habilitados) se conservan en C:\NCDiagnostics.

Diagnósticos de SLB

Errores de tejido SLBM (acciones del proveedor de servicios de hospedaje)

  1. Compruebe que software Load Balancer Manager (SLBM) funciona y que las capas de orquestación pueden comunicarse entre sí: SLBM -> SLB Mux y SLBM -> Agentes host de SLB. Ejecute DumpSlbRestState desde cualquier nodo con acceso al punto de conexión REST de controladora de red.
  2. Valide SDNSLBMPerfCounters en PerfMon en una de las máquinas virtuales de nodo de controladora de red (preferiblemente, el nodo de controladora de red principal : Get-NetworkControllerReplica):
    1. ¿Está conectado Load Balancer motor (LB) a SLBM? (SlBM LBEngine Configurations Total > 0)
    2. ¿SLBM al menos sabe sobre sus propios puntos de conexión? (Total >de puntos de conexión VIP= 2)
    3. ¿Están conectados los hosts de Hyper-V (DIP) a SLBM? (Clientes HP conectados == servidores num)
    4. ¿SlBM está conectado a Muxes? (Muxes Connected == Muxes Healthy on SLBM == Muxes reporting healthy = # SLB Muxes VMs).
  3. Asegúrese de que el enrutador BGP configurado esté emparejando correctamente con el MUX de SLB.
    1. Si usa RRAS con acceso remoto (es decir, máquina virtual BGP):
      1. Get-BgpPeer debe mostrar conectado.
      2. Get-BgpRouteInformation debe mostrar al menos una ruta para la VIP del auto SLBM.
    2. Si usa el conmutador físico de parte superior del bastidor (ToR) como BGP Peer, consulte la documentación:
      1. Por ejemplo: # show bgp instance
  4. Valide los contadores SlbMuxPerfCounters y SLBMUX en PerfMon en la máquina virtual Mux de SLB.
  5. Compruebe el estado de configuración y los intervalos VIP en Software Load Balancer Manager Resource (Recurso de Software Load Balancer Manager).
    1. Get-NetworkControllerLoadBalancerConfiguration -ConnectionUri <https://\<FQDN or IP>| convertto-json -depth 8 (compruebe los intervalos VIP en los grupos de DIRECCIONES y asegúrese de que slbm self-VIP (LoadBalanacerManagerIPAddress) y cualquier VIP accesible desde el inquilino se encuentran dentro de estos intervalos).
      1. Get-NetworkControllerIpPool -NetworkId "<Public/Private VIP Logical Network Resource ID>" -SubnetId "<Public/Private VIP Logical Subnet Resource ID>" -ResourceId "\<IP Pool Resource Id>" -ConnectionUri $uri |convertto-json -depth 8
    2. Debug-NetworkControllerConfigurationState -

Si se produce un error en cualquiera de las comprobaciones anteriores, el estado del SLB del inquilino también estará en modo de error.

Remediación

En función de la siguiente información de diagnóstico presentada, corrija lo siguiente:

  • Asegúrese de que los multiplexores de SLB están conectados
    • Corrección de problemas de certificado
    • Corrección de problemas de conectividad de red
  • Asegúrese de que la información de emparejamiento bgp se ha configurado correctamente.
  • Asegúrese de que el identificador de host en el registro coincide con el identificador de instancia del servidor en el recurso del servidor (apéndice de referencia para el código de error HostNotConnected )
  • Recopilar los registros

Errores de inquilino de SLBM (acciones del proveedor de servicios de hospedaje y del inquilino)

  1. [Hoster] Compruebe Debug-NetworkControllerConfigurationState si algún recurso loadbalancer está en estado de error. Intente mitigarlo siguiendo la tabla De elementos de acción del Apéndice.
    1. Compruebe que hay un punto de conexión VIP y que hay rutas publicitarias.
    2. Compruebe cuántos puntos de conexión DIP se han detectado para el punto de conexión VIP.
  2. [Inquilino] Validar que los recursos de Load Balancer se especifican correctamente.
    1. Validar los puntos de conexión DIP registrados en SLBM hospedan máquinas virtuales de inquilino, que corresponden a las configuraciones ip del grupo de direcciones back-end de LoadBalancer.
  3. [Hoster] Si los puntos de conexión DIP no se detectan o no están conectados:

    1. Comprobar Debug-NetworkControllerConfigurationState

      Valide que NC y el agente de host de SLB están conectados correctamente al coordinador de eventos de controlador de red mediante netstat -anp tcp |findstr 6640).

    2. Proteger HostIdla clave regkey del servicio (código de error de referencia HostNotConnected en el apéndice) coincide con el identificador de instancia del recurso de servidor correspondiente (Get-NCServer |convertto-json -depth 8).nchostagent

    3. Compruebe el identificador de perfil de puerto para que el puerto de la máquina virtual coincida con el identificador de instancia del recurso nic de máquina virtual correspondiente.

  4. [Proveedor de hospedaje] Recopilar registros.

Seguimiento de SLB Mux

La información de los Muxes de software Load Balancer también se puede determinar a través de Visor de eventos.

  1. Seleccione Mostrar registros analíticos y de depuración en el menú Ver Visor de eventos.
  2. Vaya a Registros de aplicaciones y servicios>Microsoft>Windows>SlbMuxDriver>Trace en Visor de eventos.
  3. Haga clic con el botón derecho en él y seleccione Habilitar registro.

Nota:

Se recomienda que solo tenga este registro habilitado durante un breve período de tiempo mientras intenta reproducir un problema.

Seguimiento de VFP y vSwitch

Desde cualquier host de Hyper-V que hospede una máquina virtual invitada conectada a una red virtual de inquilino, puede recopilar un seguimiento de VFP para determinar dónde pueden encontrarse los problemas.

netsh trace start provider=Microsoft-Windows-Hyper-V-VfpExt overwrite=yes tracefile=vfp.etl report=disable provider=Microsoft-Windows-Hyper-V-VmSwitch
netsh trace stop
netsh trace convert .\vfp.etl ov=yes